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Successful implementation of the Automated Repair Service Bureau 
(arse) Systems in the Bell Operating Companies is the result of the 
early integration of a variety of disciplines in the development proc- 
ess. This paper provides an overview of one of the basic human 
performance design techniques and an example of its application in 
the design of the Mechanized Loop Testing System. The expanding 
role of human performance design in the arsb systems is also re- 
viewed. 

I. INTRODUCTION 

In this issue, individuals from the disciplines of software, hardware, 
and systems engineering relate the design and development of arsb 
systems from their perspectives. In this article, we discuss one of the 
functions that psychologists perform in the design and development of 
arsb systems. This particular function is labeled personnel subsystem 
development (psd), which means the integrated design of those factors 
that affect human behavior in the system, including the design of 
manual procedures, human-machine interfaces, training, performance 
aids, and documentation as part of the total system. 1 The psd process 
also includes the systematic testing of the personnel subsystem prior 
to the initial field installation. As an illustration of psd, we will first 
give a synopsis of the process and then relate the process as it was 
applied to the Mechanized Loop Testing System (mlt). 2 Our intentions 
are not to relate a "how-to-do-it" guide but to illustrate the approach 
and emphasize that system development is not just software develop- 
ment but the integrated design of hardware, software, and human 
information processing components. 
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Fig. 1 — Automated repair service bureau human performance design process. 

II. OVERVIEW 

Consideration of human performance in the mlt system began with 
the functional requirements for mlt and continued through system 
design, development, installation, and enhancements. An overview of 
this process is shown in Fig. 1. As system requirements were defined, 
the functions to be performed by people were defined, and aspects of 
the system which would affect human performance requirements were 
identified. In the mlt system, these manual functions included such 
activities as trouble analysis and system maintenance. Specific tasks 
were then identified to describe all the manual activities within each 
function. Related tasks were combined into work modules with speci- 
fied inputs, outputs, and performance objectives. These work modules 
could later be combined to form complete jobs in the telephone 
company environment. At this point, we also provided initial specifi- 
cations for the design of the information displays (crt displays, print- 
outs, forms, etc.). With preliminary versions of system operational 
features and human/machine interfaces, we conducted a formal design 
review with systems engineers and hardware and software designers. 
This design review provided the first opportunity for everyone involved 
in the design process to review the proposed system operation from 
the user's perspective. 

When the initial design was complete, we conducted laboratory 
evaluations of work module design and preliminary documentation 
and training under conditions simulating actual system operation. For 
these evaluations, telephone company personnel who met the specified 
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minimum skill and knowledge requirements received training on the 
new activities. During the simulation, the participants processed typ- 
ical inputs as they would on the job. Performance data were collected 
during the simulation, and the participants were interviewed to deter- 
mine their subjective reactions to the system design, training, and 
documentation. If data from the evaluations indicated that redesign 
was required, the procedures and human/machine interfaces were 
redesigned prior to the development of final user documentation. 

This design process was highly iterative, with changes at each phase 
affecting design decisions made earlier, as shown in Fig. 1. But the 
most significant effect of this approach was the impact on the design 
of the software. At each phase, as various design decisions were 
reviewed or tested, many recommendations for software changes were 
made and implemented to improve the total system. This process 
illustrates a view of the system as an integrated unit of people and 
machines processing information to achieve stated objectives. This 
view of the system requires that human performance considerations 
be integrated with software design from the earliest phases of system 
development. 

The final stages of the human performance design process for mlt 
involved the preparation of user documentation and training for the 
field trial. We then trained the Repair Service Bureau personnel at 
the trial site and monitored their on-the-job performance during the 
field trial. Follow-up activities included field evaluations of human 
performance within the system and recommendations for design 
changes to improve overall system operation. 

III. EXAMPLE FROM MLT SYSTEM DESIGN 

To illustrate the impact of this design process on the mlt system, 
we will describe the initial design and subsequent redesign of a specific 
manual function. As a result of the initial examination of system 
functions, the trouble analysis function was defined to include all the 
manual activities that must be performed when a trouble report is first 
printed in the work center. These activities consisted of the examina- 
tion and integration of the trouble description, line record information, 
and automated test results to determine what the next stage of 
processing should be. 3 As a result of the initial task analysis, one work 
module was designed to accomplish all the activities in the trouble 
analysis function. 

The primary input to this work module was the Basic Output Report 
(bor) containing line record information, the trouble description, and 
detailed test results. The output of this module was a decision to route 
the report for either manual testing, additional automated testing, 
dispatch, or close out. Some design work had previously been done on 
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B(211) CAPIMBAL 





Fig. 2 — Original test results format. 

both the content and the format of the test results displayed on the 
bor (Fig. 2), and this was accepted as the initial human/machine 
interface design. 

This initial design of the test results output and trouble analysis 
procedures was based on two major assumptions. First, we assumed 
that in-depth interpretation of all the detailed test results would be 
required for all trouble reports. Therefore, very little interpretation of 
the raw test results was provided by the software. All results were 
displayed, along with software codes, in the order in which they were 
obtained during the mechanized testing process. We also assumed that 
a person's prior trouble analysis experience" in' the manual Repair 
Service Bureau, plus some limited training in the new test results, 
would enable him or her to accurately analyze and process trouble 
reports containing mlt results. Therefore, the original training focused 
on providing "translations" of the new test results into familiar terms, 
with little procedural instruction in the integration of the test results 
with other information on the bor to make trouble report routing 
decisions. 

To gather performance data to validate these assumptions, we 
conducted a laboratory evaluation of this work module. Four operating 
telephone company craft employees who met the specified minimum 
requirements were given the work module training. Then they proc- 
essed trouble reports (bors) selected to provide a valid sample of the 
trouble descriptions, line records, and test results found in typical 
Repair Service Bureau operations. Analysis of the performance data 
revealed that the participants incorrectly routed 16 percent of the 
trouble reports, and most of these errors involved routing troubles for 
manual testing when the mlt test results provided sufficient informa- 
tion to directly dispatch the trouble report. Since a major goal of mlt 
was to reduce the number of troubles that required manual testing, 
this error rate would have a significant adverse effect on overall system 
operations and economics. 

Based on the performance data and comments from the evaluation 
participants, we reexamined the initial assumptions and redesigned 
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MLT RESULTS: VER 42 OPEN OUT. TIP, DISTANCE 


■ 24,032 FT. 


OPEN OUT 


3 TERMINAL DC VOLTAGE 


OPEN TIP 


0.00 VOLTS T-G 


CAPACITIVE BALANCE 


0.00 VOLTS R-G 


= 92.77 PERCENT 


3 TERMINAL AC RESISTANCE 


DISTANCE TO OPEN 


1012.23 K OHMS T-R 


= 24,032 FT 


845.34 K OHMS T-G 


VALID DC RESISTANCE AND VOLT 


710.76 K OHMS R-G 


3 TERMINAL DC RESISTANCE 


CROSSBAR, NO LINE CKT TEST 


> 3500.00 K OHMS T-R 




> 3500.00 K OHMS T-G 




> 3500.00 K OHMS R-G 





Fig. 3 — Test results format — field trial. 

both the human/machine interface and the analysis procedures. It was 
evident that some interpretation of the detailed test results could be 
accomplished by a software algorithm and that a brief summary 
statement could be provided at the beginning of the full test results 
(Fig. 3). Therefore, many routing decisions could be based solely on 
the summary without detailed examination of all the test results. In 
addition, extraneous information not needed for trouble analysis (e.g., 
software codes, nonsignificant digits) was eliminated. The detailed test 
results describing the fault condition were presented at the beginning 
of the results to facilitate trouble diagnosis. Training and documenta- 
tion of the analysis procedures were expanded to include decision 
guidelines in a performance aid for work center personnel. 

We expected that the redesigned procedures and output format 
would enable a clerical level person to process many trouble reports. 
Also, fewer trouble reports would be routed incorrectly, thus reducing 
the need for manual testing. Data from a follow-up field evaluation 
confirmed these expectations concerning the effectiveness of the rede- 
signed procedures and test results. In some work centers, clerical 
people were processing all of the trouble reports, with fewer instances 
of incorrect routing than were found in the laboratory evaluation. 

Continuing engineering of the mlt system has resulted in refine- 
ments and improvements in the testing hardware and the software 
algorithms that control testing. Similarly, follow-up studies of field 
installations have provided more detailed information on the relation- 
ship between various line fault conditions and specific mlt test results. 
This information on the operational use of the system has been used 
to enhance the software interpretation of the detailed test results to 
provide over 50 additional test-result summaries. Based on the results 
of field evaluations of several mlt installations and a laboratory study 
comparing human performance on alternative test-results formats, 4 
the display format has also been redesigned, as shown in Fig. 4. This 
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VER42: OPEN OUT CABLE TIP- CAP BAL 92% 
DISTANCE FROM STATION 1800 FT 
DISTANCE FROM CO. 24000 FT 




CRAFT: DC SIGNATURE 
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BALANCE 
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OPEN DISTANCE 
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FROM CO =24000 FT 



Fig. 4 — Proposed test results format. 

new format provides most of the test results information required for 
rapid trouble analysis in the summary. In addition, the summary will 
include the information to be relayed to outside repair technicians on 
dispatch. 

IV. COMMENTS 

The process of human performance design begins with and not after 
the development of system requirements. Human performance consid- 
erations begin not with a review of the requirements document but 
with an understanding of what the system is supposed to accomplish 
and the examination of alternative approaches. 

The role of human performance designers in the design and devel- 
opment of the arsb systems is continuing to grow along with the 
evolution of the systems. The initial systems were designed to mech- 
anize the more routine, repetitive tasks performed by clerical or craft 
personnel (e.g., trouble report tracking, initial line testing). With the 
mechanization of many of these routine activities, more recent arsb 
systems are addressing more complex craft and managerial activities. 
For example, the next generation of the mlt system will provide 
computer-assisted loop testing and analysis currently performed by 
experienced craft persons using old, but functional, work positions. 
The complexity of the information processing activities requires that 
the design of all system components be closely integrated. 5 Similarly, 
systems such as cras and Predictor are used by managers to support 
their decision making in such areas as plant analysis, force manage- 
ment, productivity, and budgeting. 6 In the design of these new decision 
support systems, the psychologist as designer and developer will play 
a major role, since these systems now address the issues of problem 
solving, direct managerial use of the system, design of the system for 
group problem solving, the incorporation of models and artificial 
intelligence to support decision making, the evaluation of systems in 
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supporting decision making, and a host of other complex human- 
computer issues. 

As the role of human performance designers increases, so does the 
variety of tools and techniques applied during the design process. The 
basic systematic design process illustrated here is employed in the 
design of arsb systems. In addition, laboratory experiments and field 
studies have been conducted to address specific design issues. 6 Areas 
such as job quality are being examined, both in existing arsb systems 5 
and in current system design efforts. 

For the development of arsb systems, it has been effective to 
dedicate and organize psychologists on a group level to a particular 
system development effort. In their system design and development 
work, these people draw on numerous branches of Psychology and 
Engineering, including Experimental, Social, Cognitive, and Organi- 
zational Psychology, Industrial Engineering, and Human Factors. This 
dedication and continuity of effort ensures that systematic human 
performance design takes place as opposed to having the psychologist 
intermittently critique the development efforts with the result of a 
retrofitted system at best. 
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